Promote to main: close the stamp ownership hole - #315

* Stop strangers storing data on batches the gateway paid for

check_access() allowed any caller to use a batch absent from the ownership
registry, commented "backward compatibility" for batches predating it.

The set that default actually covered was not legacy callers. Every path by
which a caller obtains a batch already registers it — /pool/acquire,
POST /stamps/, /stamps/for-owner. What it covered was the POOL'S OWN INVENTORY:
ownership was recorded when a caller ACQUIRED a batch, never when the pool
bought one, so everything sitting in the pool was untracked and therefore
writable by anyone who knew its id. Batch ids are not secret; GET /stamps/
lists them.

A production pool batch is 50% utilised having never been acquired. That is
capacity the gateway funded, consumed by someone who never asked for it, on
batches it pays roughly 0.018-0.14 BZZ a day each to keep alive.

Two changes, in the order the fix requires:

Pool inventory is registered as POOL_OWNER at purchase (add_stamp_to_pool) and
adopted on sync, so batches bought before this change are protected too rather
than staying open for the rest of their lives. Registration failure never fails
a purchase — the batch exists and was paid for — but logs that it is
unprotected until registered.

check_access then refuses POOL_OWNER outright, and refuses untracked batches
instead of allowing them. Acquiring re-registers the batch to the caller, which
is the only way to get one.

STAMP_OWNERSHIP_ALLOW_UNTRACKED restores the old behaviour, for one situation:
STAMP_OWNERSHIP_FILE is lost, every batch becomes untracked at once, and
legitimate owners would be locked out of batches they paid for. A test pins that
permissive mode does NOT reach pool inventory — recovering from a lost registry
must not reopen the hole it is recovering from.

tests/test_stamp_ownership.py::test_untracked_stamp_allowed asserted the old
behaviour and now asserts the new one. Three tests added: permissive mode,
pool inventory refused to paid/free/anonymous callers alike, and permissive mode
not unlocking pool inventory.

Full suite: 1078 passed, 25 skipped.

Closes #312.

* Test that the pool claims what it buys, not just that the check works

The enforcement tests construct registry state by hand, so they pass whether or
not any code registers anything. Nothing asserted that add_stamp_to_pool or
sync_from_bee_node call register_stamp at all — meaning the lock was tested and
the door was not, which is the same asymmetry that let #312 stay open.

Three tests:

  a purchased batch is registered to POOL_OWNER with source pool_purchase
  a registration failure does not lose a batch already paid for
  sync adopts pre-existing inventory, so batches bought before this change are
    protected rather than staying open for the rest of their lives

The second matters because the batch exists on chain regardless: raising there
would drop it from the pool while the money is spent, which is worse than an
unprotected batch. It is logged instead, and the log says it is unprotected.

The sync test initially failed with synced == 0 — the fixture omitted `local` and
`usable`, which sync filters on. Fixed by matching the record shape the other
sync tests use.

TEST_STRATEGY.md records why both halves are needed.

Full suite: 1081 passed, 25 skipped.

* Report gateway inventory as 'pool', not as free for anyone to use

Found reviewing this PR. accessMode is computed as:

    "owned" if ownership_info.get("mode") == "paid" else "shared"

Pool inventory registers with mode="pool", which is not "paid", so it fell
through to "shared" — the value that tells a client the batch is free for anyone
to use, about exactly the batches check_access now refuses. A client reading the
listing would believe it and be denied on upload, which is worse than the
original defect in one respect: the API would be actively misleading rather than
merely permissive.

Neither existing value was honest. "shared" invites use; null means "unknown to
the registry", which it is not. So the Literal gains "pool" and the field
description says how to obtain one — acquiring re-registers it to the caller.

Two tests: the owner-to-accessMode mapping for all three cases, and that the
Literal permits "pool" (it is validated at serialisation, so an unlisted value
would fail at runtime rather than at import).

provenance-smasher asserts accessMode membership against a fixed list and would
have failed on every pool batch. Covered by provenance-smasher#31, which must
merge before this deploys.

Full suite: 1083 passed, 25 skipped.